Skip to content

fix: 🐛 use duckplyr to read Parquet as DuckDB - #348

Merged
lwjohnst86 merged 4 commits into
dp-next:mainfrom
Aastedet:duckplyr-read-parquet-duckdb
Aug 5, 2026
Merged

fix: 🐛 use duckplyr to read Parquet as DuckDB#348
lwjohnst86 merged 4 commits into
dp-next:mainfrom
Aastedet:duckplyr-read-parquet-duckdb

Conversation

@Aastedet

@Aastedet Aastedet commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Description

Changes read_parquet_dataset() and read_parquet_file() to use duckplyr::read_parquet_duckdb() instead of arrow::open_dataset()/arrow::read_parquet()

This provides more robust support for duckplyr verbs and avoids errors/bugs as mentioned in #346.

Closes #346

The change to the functions is small, and only a few edits to test-read.R and test-use.R were necessary. The only substantial change to the tests is the removal of the test for incompatible schemas in test-read.R, which was necessary because duckplyr::read_parquet_duckdb handles this very differently from how arrow::open_dataset() does: if a variable's type differs between Parquet files, it is silently/automatically converted/promoted to a compatible type if at all possible and no error is thrown. I could not find a an option/flag to change this behavior.
I'd argue that, as a user this is actually the preferable behavior, since it doesn't require debugging/re-running the whole conversion, but just a single mutate() call to force the desired type.

I've kept the use of arrow::open_dataset in test-convert.R untouched for two reasons:

  • The purpose of those tests is to verify the conversion from SAS/writing of the Parquet file, not the subsequent loading.
  • Reading in the data with duckplyr::read_parquet_duckdb leads to some minor discrepancies in types and attributes in the data (described in the linked issue) that cause expect_identical() to fail vs. haven-read tables, so it's a bit more messy to run those tests with duckplyr in the pipeline.

Needs a quick/thorough review.

Checklist

  • Ran just run-all

@Aastedet

Copy link
Copy Markdown
Contributor Author

I assume that the failing GHA is a fastreg thing and not on my end, but let me know if I should look into it.

@lwjohnst86 lwjohnst86 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Just some comments ☺️ and yes, the failing GHA is for adding to the board (not sure why)

Comment thread R/read.R Outdated
Comment thread tests/testthat/test-read.R
@Aastedet

Aastedet commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

I've updated the PR to keep the outputs as duckplyr_df (read functions and tests). The pre-commit check appears to have timed out as I was merging changes from the base branch on GitHub, but otherwise it passes.

@Aastedet
Aastedet requested a review from lwjohnst86 August 3, 2026 09:41

@lwjohnst86 lwjohnst86 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cooool 👍

@lwjohnst86
lwjohnst86 merged commit 815ff29 into dp-next:main Aug 5, 2026
9 checks passed
@github-project-automation github-project-automation Bot moved this from In review to Done in Platform development Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Limitations on the DuckDB view created by arrow::read_dataset() |> arrow::to_duckdb() in the read_* functions

2 participants